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THE DBC/1012 DATA BASE COMPUTER SYSTEM 



The DBC/1012™ utilizes a parallel processing architecture comprised of Interface Processors (IFPs), 
Communication Processors (COPs), Access Module Processors (AMPs), and high-speed Winchester- 
type Disk Storage Units (DSUs). The proprietary Ynet™ coordinates the activities of these components 
to insure that the sum of their processing power is realized as one work force. Rows of each relational 
table are evenly distributed over the available DSUs. The system's superior performance is achieved 
by all AMPs working as a "team" with their portions of the data. 

A DBC/1012 may be configured with as few as 3 and as many as 1024 processors. Each AMP may 
have one or two DSUs. 
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(A DBC/1012 with the single DSU option.) 



Software for both the DBC/1012 and each supported host/workstation environment is also included 
in the system. Each host or workstation runs a Teradata Director Program (TDP) that manages the 
traffic to and from the DBC/1012. Additional interfaces are available for CICS, TSO, CMS, PL/1, and 
COBOL. 






THE TERADATA ADVANTAGE 



PRICE & PERFORMANCE 

The DBC/1012 Data Base Computer System achieves the same 
performance as a mainframe for approximately 1/4th the cost. 
Moreover, it achieves performance levels exceeding the most 
powerful mainframes. This is accomplished through the use of 
microprocessor subsystems and parallel processing. 




CONNECTIVITY & SHAREABILITY 

Teradata's open systems architecture strategy, called a "shared 
information architecture," incorporates information delivery tools, 
a variety of processing environments, and the DBC/1 01 2 as a 
shared relational data base management system. The DBC/1012 
can be connected to multiple host mainframes at the same time. 
Each host may run a different operating system (MVS, VM, 
CCOS8, UNIX). This sharing of data by multiple hosts eliminates 
the need for costly data duplication while solving the associated 
problem of concurrent data access. 
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MODULARITY 

With the DBC/1012, capacity may be added in low cost 
increments. There is no need to acquire excess capacity. Thus, the 
need to spend today's dollars for tomorrow's needs is greatly 
reduced. This advantage is particularly important when usage is 
growing rapidly or usage growth is hard to predict. 




RELIABILITY 

The DBC/1012 is fault- tolerant. It has fully redundant circuitry and 
software, as well as a "fallback" data protection option. Data 
availability exists even if disks or processors fail. What's more, all 
recovery is automatic — there is no requirement for operator 
intervention. 






Fail-Safe Operation 

• Fault Tolerant Architecture 

• Automatic Recovery 

• Data Availability 



RELATIONAL PRODUCTIVITY 

The DBC/1012 employs the relational model data base 
management system. Through a data access language called 
DBC/SQL, end-users and programmers can enjoy the same easy- 
to-use data base system. The result is typically better than a two- 
fold improvement in productivity. 
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Relative Time and Cost of 
Application Development 
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TERADATA CORPORATION 



Headquartered in Los Angeles, California, Teradata was incorporated in 1979. Over four years of development were 
required to produce the DBC/1012 Data Base Computer System. While the company now supports a prestigious 
customer base, it continues development efforts, enriching the functionality and price/performance of the 
DBC/1012. 

PROVIDING STRATEGIC TECHNOLOGY . . . 

Teradata customers state that the DBC/1012 is a strategic component in their 
information systems plans. These companies are typically information-intensive 
businesses with a strong eye to the future. The most common applications involve 
large data bases where both production systems and end-user queries need to be 
concurrently supported. 



AND COORDINATED PRODUCTS . . . 

Teradata is in the data base computer business. However, users of the DBC/1012 also 
need information delivery tools to enhance the usage of the stored data. Interfaces 
are available to popular software packages such as: INTELLECT— a natural language 
query system; NOMAD2 — a 4th generation programming language; PC/SQL-link — 
SQL-based software supporting PC-to-mainframe interaction; IDEAL— a high-level 
application development tool; DATAQUERY — an interactive tool for the end user; 
and FOCUS — a 4th generation language for end users. 



WITH A COMMITMENT TO CUSTOMER SUPPORT 

"Our last customer is more important than the next." This motto emphasizes 
Teradata's commitment to customer service and support. Sales and service offices exist 
in the following areas: 



ATLANTA 
(404) 980-1143 

BOSTON 
(617) 239-8069 

CHICAGO 
(312) 297-7400 



CINCINNATI 
(606) 341-3307 

DALLAS 

(214) 490-6500 

DETROIT 
(313) 262-1391 



FLORIDA 
(305) 660-2522 

LOS ANGELES 
(213) 827-8777 

NEW YORK 
(516) 747-1160 
(201) 563-1110 



SAN FRANCISCO 

(415) 362-1028 

SEATTLE 

(206) 575-0911 

TORONTO, CANADA 

(416) 492-8092 



UNITED KINGDOM 
011-44-(0372) 68933 

WASHINGTON, D.C. 
(703) 847-3112 
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DBC/W12 Data Base 
Computer System 



The DBC/1012 is a high performance, fault-tolerant computer system optimized for relational database management. This 
microprocessor-based system is expandable in small modules of processing and storage capacity. The minimum configuration 
includes a processor subsystem and a storage subsystem, providing up to 24 MIPS (millions of instructions per second) of processing 
capacity and up to 19 gigabytes of storage capacity, depending on options. The system can be expanded to more than 3 BIPS (billions 
of instructions per second) and nearly 5 terabytes of data storage, all operating as a single system with a single image. 




Disk Storage 



The system incorporates high-speed disk 
storage units (DSUs) which can be con- 
figured to provide nearly 5,000 gigabytes 
of database storage. 



Ynet 



The Ynet high-speed intelligent intercon- 
nect is the heart of the system's proprie- 
tary parallel processing architecture. It is 
designed to harness the power of 3 to 
1,024 processors. 



The DBC/1012 integrates three types of 
processors: Interface Processors (IFPs), 
Access Module Processors (AMPs), and 
Communications Processors (COPs). The 
IFP provides connection to mainframe 
hosts; the AMP manipulates the database, 
accesses DSUs and prepares the data re- 
sults; the COP provides connection to a 
local area network, enabling user access 
from minicomputers, workstations and 
personal computers. 



Relational Answers to Complex Questions 







Substance Research 

Applying an iterative process, iden- 
tify a unique set of chemical sub- 
stances that possess specific charac- 
teristics which can be applied to new 
pharmaceutical chemicals. 




Advertising Return 

Which products advertised this week 
exceeded their weekly sales average 
by more than 10% in the targeted 
regions? 




Passenger Load Factors 

What is the potential impact of the mileage bonus 
program on full-revenue seats for transoceanic routes 
during the holiday season? 




Premium Prospects 

How many $70,000 households write more than 25 
checks per month, maintain an average balance of more 
than $3,000 and have a credit card account? 




Service Availability 

What percentage of the communications network has 
been out-of-service for more than one minute during the 
last two-hour period? 




The DBC/ 1012 
Data Base Computer 

Flow of an Information Request 



1 . The user's SQL is captured by the Teradata Director Program 
(TDP) and promptly dispatched to the DBC/1012 where it is 
received by an Interface Processor (IFP) and translated into 
relational database worksteps. 



2. The Ynet broadcasts the request's worksteps to the Access 
Module Processors (AMPs). Each AMP processes the workstep 
with its associated Disk Storage Units (DSUs). AMPs work in- 
dependently, but at the same time on the same request - in 
parallel. 
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3. Since the rows of all database tables are distributed evenly 
across the DSUs, all AMPs work with an equivalent portion of the 
database. Working in parallel, each AMP selects the rows within 
its DSUs that qualify for the request and posts the necessary 
columns (fields) to the Ynet. 



4. The Ynet performs a hardware sort/merge, collating each 
AMP's response set into one master answer set. The sort se- 
quence is determined by the Order clause of the original SQL 
request. The answer set (file) is then sent back to the host by an 
IFP and posted to the requesting user's application area. 
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Multi-Platform Connectivity 
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Local Area Network 



Local Area Network 




The DBC/1012 can service multiple host mainframes, minicomputers, workstations and personal computers simultaneously. This 
enables a shared database environment that simplifies the complexities of data management. It reduces the need for redundant data 
storage and its associated cost, while ensuring greater data integrity. 



Supported Systems: 

IBM(MVS,VM,TPF) 
UNISYS (OS 1100) 
Amdahl (UTS) 
Siemens (BS2000) 



DEC (VAX/VMS) 
AT&T (3B2/UNIX) 



MS-DOS 

Metaphor 

Sun Microsystems (UNIX) 



A Teradata 
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Los Angeles, CA 90066 
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"The DBC/I012 takes existing microcomputer and disk technologies 
and marries them with the Ynet to produce a system that is greater 
than the sum of its parts." 

— Dr. Philip M. Neches 
Chief Scientist 



The Teradata DBC/1012™ is the first complete data base 
computing system. It is wholly original in concept and 
execution, yet its basic subsystems are built from proven 
industry-standard components. Reliable, high-speed 
Winchester-type disks are the storage media. Microcomputers 
supply the processing power. Combined with the Teradata 
patented Ynet™ technology, these elements produce a totally 
integrated system solution for data base management. 

This unique architecture of hardware, firmware and 
software permits the DBC/1012 to exploit the full 
functionality of the relational model for data management. By 
leveraging multiple microprocessor subsystems to the 
problem, the DBC/1012 achieves the performance levels 
required to support concurrent end-users and production 
systems activity. 

But, performance is only one of the outstanding advantages 
of the DBC/101 2 Data Base Computer System. It is also 
shareable by multiple mainframe computers, department- 
level systems or workstations running the same, or different 
operating systems. This capability reduces the need for 
replicated storage structures and multiple data base 
management systems. Additionally, the fault tolerant nature 
of the DBC/1012 and its automatic recovery features provide 
a reliable, fail-safe environment. Thus, data — the main 
resource of the information system — are secure and 
consistently available to a variety of processing components. 

Growth expansion and adaptability are other key DBC/1012 
features. Its modular nature permits capacity to be added to 
an existing system in any increment without data center 
disruption. Because it internally distributes activity between 
transaction processors and data base processors, the system 
may be configured to the functional balance best suited for 
the workload demands. Thus, the DBC/1012 is adaptable to a 
vast spectrum of application environments. 

The DBC/1012 Data Base Computer System is responsive, 
reliable, and resilient to change. More importantly, it 
provides a return-on-investment (ROD that cannot be 
equalled by the all-software, DBMS approach. The DBC/1012 
is the first of its kind — the first complete data base 
computing system. 
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Parallel Processing Breaks the DBMS Bottleneck 

The DBC/1012 employs a parallel processing approach that is 
not found in traditional data base management system 
implementations. Instead of servicing the data management 
workload serially, as in a uniprocessor mainframe 
environment, the DBC/1012 distributes the activity to many 
processors that collectively work as a team (in parallel). The 
processing burden imposed by any given request is 
subdivided into smaller tasks which are distributed among 
multiple processors. 

In the DBC/1012, multiple microprocessor subsystems with 
data base management software work against their individual 
disk storage units which contain appropriate portions of the 
overall data store. All processors respond to a globally 
broadcast problem and then proceed, asynchronously, to 
process their individual portions of the data base. The 
aggregate of the computational power derived from all 
processors is applied to the problem and the sum of the I/O 
rates of each disk unit is similarly realized. The more 
processors and disks, the faster the response. 

Thus, the processing bottleneck that is so frequently 
encountered by the monolithic mainframe data base system 
is eliminated. The DBC/1012 represents a new standard for 
throughput and response time. 

The Relational Model and DBC/SQL 

The DBC/1012 Data Base Computer System implements the 
relational model for data base management — an approach 
that is generally recognized as having superior characteristics 
in the areas of data handling and ease of use. However, until 
now, all relational systems contained trade-offs between 
functionality and performance that compromised the 
advantages of the model. The DBC/1012 is the first system, 
combining hardware and software, to fully exploit the 
richness of the relational model. 

DBC/SQL is the user's window to the system. It is a non- 
procedural data language that may be used effectively by 
programmers and non-data processing professionals alike. 
Compatible with the emerging industry-standard SQL 
(Structured Query Language), DBC/SQL is composed of 
simple English-like commands that allow the user to state 
what data is needed, without having to specify how to get it. 



TDP is re-entrant and therefore capable of directing multiple 
sessions of activity concurrently. 

When the DBC/1012 is shared by multiple hosts, as shown 
in Figure 3, each host machine runs its own TDP. Other host 
software packages are supplied by Teradata. Each insulates 
the user from low-level interactions by automatically 
managing the Call-Level Interface to the TDP. These useful 
tools include: 

• ITEQ (Interactive TEradata Query) — permits interactive 
terminal users to establish a direct DBC/SQL dialogue with 
the DBC/1012. ITEQ is an application program that runs 
within MVS/TSO and VM/CMS. 

• BTEQ (Batch TEradata Query) — an easy to use facility with 
report formatting functions used to submit scripts of 
DBC/SQL statements, as well as export data from the 
DBC/1012 to host data sets. 

• COBOL and PL/1 Preprocessors— programmer aids that 
permit DBC/SQL statements to be embedded in source 
code. They may be used for batch programs or on-line 
applications running under IBM's Customer Information 
Control System (CICS). 

• Data Base Administration Utilities — a full set of powerful 
tools for dumping, restoring and bulk-loading data bases. 

• Coordinated Products — Popular software developed by 
other companies: e.g., NOMAD2, a 4th generation 
language system for end users, and IDEAL, a high-level 
application development tool, and many other packages. 



Interface Processors 

Interface Processors (IFPs) manage the dialogue between 
users on a mainframe and the other subsystems of the 
DBC/1012. Each IFP incorporates a channel adapter, a CPU 
and two high-speed Ynet interfaces. 

DBC/SQL statements are received by an IFP. Its software 
then translates the requests, dispatches appropriate work- 
steps and routes data responses back to their requestors. 

A minimum of two IFPs per host is required for fail-safe 
operation. However, more may be added as required (as in 
Figure 3) depending on the number of hosts to be serviced 
and their respective traffic volumes. 



A System of Subsystems 

The DBC/1012 is a complete system solution for relational 
data base management. Its modular structure is a system of 
subsystems. It synergistically combines host or workstation 
interface software, Interface Processors (IFPs), Communication 
Processors (COPs), Access Module Processors (AMPs), Disk 
Storage Units (DSUs), a system console and the Ynet 
interconnect logic — the enabler for parallel processing. 

Host Interface Software 

As Figures 1 and 2 indicate, the DBC/1012 communicates 
with a mainframe via one or more block multiplexer 
channels, or departmental systems and workstations via a 
local area network (LAN). Inside the host, the Teradata 
Director Program (TDP) operates in its own address space or 
virtual machine. It manages the channel activity while 
servicing request/ response traffic from other address spaces. 



Access Module Processors 

Access Module Processors (AMPs) perform the data base 
manipulation activities. 

Each AMP is responsible for one or two DSUs as shown in 
Figures 1 and 2, respectively. The AMP software executes 
data base manipulation work steps, accesses the disk(s) as 
appropriate and prepares the resulting data. 

Data records (or, more properly, rows of a relational table) 
are distributed evenly across all DSUs in the system. In the 
configuration illustrated by Figure 1, each AMP/DSU would 
maintain approximately one-fourth of each relational table in 
the data base. In Figure 3, where there are sixteen 
AMP/DSUs, each would maintain a sixteenth, etc. 

When a relational request is received that requires the 
manipulation of multiple rows, each AMP fields the request 
and works asynchronously upon its portion of the data base. 
All AMPs work concurrently on the same problem in parallel. 
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Communication Processors 

Communication Processors (COPs) manage the dialogue 
between users on a department-level (mini) computer or 
workstation (PC) and the other subsystems of the DBC/1012. 
Each COP incorporates a local area network (LAN) adapter, a 
CPU, and two high-speed Ynet interfaces. DBC/SQL 
statements are received by a COP. The software then 
translates the request, dispatches appropriate work steps and 
routes data responses back to the requestors. 

A minimum of one COP per department-level processor or 
workstation is required for operation. More may be added as 
required depending on the number of hosts to be serviced 
and their respective traffic volumes. 

Disk Storage Units 

High-speed, large volume Winchester-type DSUs are used in 
the DBC/1012. The storage area of each disk is formatted to 
accommodate system work areas for such tasks as sorting and 
spooling, prime storage for relational data, and optional 
fallback areas where critical data may be intentionally 
duplicated. 

Fallback Option 

When FALLBACK is specified, a copy of the prime data of 
each DSU is distributed evenly across other DSUs. Should a 
DSU fail, the DBC/1012 automatically directs requests for its 
data to the other supporting drives, which team together to 
substitute for the failed unit until it has been repaired. At that 
time, the DBC/1012 automatically re-establishes the primary 
copy of the data using the fallback copy, including any 
changes that may have been made to that data while the 
DSU was down. Data remains consistent and available. 

The Ynet 

The patented Ynet is the heart of the DBC/1012 and the 
enabling technology for true parallel processing. In contrast 
to ordinary bus structures, the Ynet is an active array of high 
speed logic. 

A DBC/1012 system contains two fully redundant Ynets, so 
that the failure of one does not prevent the system from 
operating normally. All processors (IFPs, COPs and AMPs) 
interconnect to both Ynets. 

As a tree-structured network of packet-sorting elements, the 
Ynet performs three functions. It broadcasts work messages 
from the IFPs or COPs to the AMPs, manages AMP to AMP 
communications and then merges data results from AMPs 
back to IFPs or COPs. 

With the Ynet, the power of many microprocessors 
operating in parallel can be harnessed and logically treated as 
a single, much larger processor. The Ynet is capable of 
interconnecting up to 1024 processors. 

System Flow 

The services of the DBC/1012 may be exercised by both 
interactive and batch environments running within the host 
computer or workstation. In either case, requests for data are 
expressed with DBC/SQL statements. Teradata's host interface 
software transfers a DBC/SQL request from the user to the 
TDP, and then transmits over a block multiplexer channel to 
an IFP. Similarly, a COP accepts requests from the user 
program in a minicomputer or a PC workstation. 



It is important to note that the DBC/SQL requests which 
are sent to the DBC/1012 are in source language format. No 
language processing occurs in the host. 

IFPs or COPs receive incoming DBC/SQL requests and 
parse (translate) them. Using the active DBC/1012 Data 
Dictionary/Directory, the IFP or COP determines the validity 
of each request and whether the originating user or program 
is authorized to perform the operation. The IFP or COP 
determines the work steps necessary to service the request 
and then dispatches these instructions over the Ynet to one 
or more AMPS — depending on whether the request is for a 
single row or for a number of rows. 

AMPs accept the work steps transmitted by an IFP or COP 
and perform the indicated functions. They manage the 
retrieval of data as well as all changes made to that data. 
Inter-AMP communication is invoked for numerous 
operations such as the relational join and concurrency 
control. 

AMPs prepare data results for the Ynet. If the request 
included sequence ordering, each AMP will sort its results 
accordingly. Once all AMPs are ready, the Ynet merges 
(collates) the results back to the dispatching IFP or COP. 

Completed data responses are sent back to the host under 
the IFP's or COP's supervision. A small set of responses can be 
managed in one transmission. Larger response sets are 
spooled and sent a block at a time. 

TDP coordinates the DBC/1012 response flow and directs 
the data results back to the requesting user. Teradata- 
supplied software, such as ITEQ, BTEQ, and language 
preprocessors, assure that enough buffer space is available to 
efficiently receive the returned data. 



System Modularity 

The DBC/1012 Data Base Computer System is modular. The 
customer may configure as many IFP, COP and AMP 
subsystems as required in order to process the workload 
within a desired level of performance. 

DBC/1012 configurations are determined from two 
categories of requirements: the volume of the request traffic 
and the characteristics of the data base. If one IFP or COP is 
capable of supporting n requests per second, and the 
workload is 6n, then six IFPs or COPs are needed. 

The number of IFPs is also influenced by the number of 
host computers that will share the DBC/1012 data resource. 
In Figure 3, three hosts are shown with the IFPs required to 
service their unique request volumes. 

The number of COPs required is influenced by the number 
of department-level systems or PCs required to support the 
application, the number of local area networks which are to 
be attached to the DBC, and the data or traffic volume across 
those LANs. In Figure 3, two COPs are shown as sufficient to 
handle the expected load from the workstations or 
department-level machines attached to them. 

The size of the overall data bases (including FALLBACK and 
work areas) as well as the scope of the data manipulation 
requirements determine the number of AMPs and DSUs. 

The two IFP, four AMP systems indicated in Figures 1 and 2 
are modest configurations. The DBC/1012 shown in Figure 3 
is a more powerful configuration capable of servicing a larger 
workload. 






Capacity Growth in Easy Steps 

The DBC/1012 accommodates capacity growth in 
manageable, incremental steps. There is no need to install 
"excess" processing or storage capacity. The user may add-on 
any increment of IFPs, COPs, AMPs or DSUs as may be 
required at the time. A system may be expanded to a 
maximum of 1024 processors. 

As the system grows and new processors are added, there 
is no need to unload the data base, then reload after the 
additional equipment is installed. When a system is 
expanded to add AMPs and DSUs, an internal DBC/1012 
utility automatically redistributes the data (including 
FALLBACK) to populate the new processors. This minimizes 
the costly operational disruption normally encountered when 
adding disk storage capacity to an existing system. 

System for All Users 

The DBC/1012 supports access from both end-users as well 
as on-line and batch programs. End-users can retrieve data 
through ITEQ, BTEQ, or coordinated products, while batch or 
on-line programs access data using embedded DBC/SQL 
statements. This is the first system where both groups of users 
are able to work effectively with the same relational data. 

System Performance 

The response times that can be achieved with the DBC/1012 
are outstanding. Simple requests can be satisfied as quickly as 
with conventional systems, while complex requests run 4 to 
100 times faster than conventional systems, depending on 
the number of processors in the configuration. By distributing 
the workload over parallel processors, the DBC/1012 avoids 
the performance bottleneck that is common in a mainframe 
CPU. 

DBC/1012 Hardware Specifications 

The DBC/1012 components are housed in handsome faceted 
cabinetry. Two subsystem cabinets exist: one for processors 
and the other for disk storage units. Both require the same 
floor space and are distinguished from the exterior by their 
display panels. 

Dimensions (Single Cabinet) 

Width 74 cm (28") 

Depth 91 cm (36") 

Height 152 cm (60") 

Subsystem cabinets are grouped by twos or threes: a 

processor cabinet plus one or two storage cabinets. A system 

console and printer are provided as part of each DBC/1012 

system. 

A processor subsystem cabinet accommodates up to eight 
processors (AMPs, IFPs and COPs) plus dual (redundant) Ynet 
interconnection. A storage subsystem cabinet can house from 
four to eight DSUs, depending on the disk option selected. 

Processor Modules 

The IFP, COP and AMP microprocessor subsystems are each 
composed of two high speed state machines for interfacing 
with the two Ynets, and three microprocessors; a Central 
Processing Unit (CPU), a Numerical Processing Unit (NPU) 
and an I/O Processor. All of these processing components 
share a common memory resource. 
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Each processor module requires four Printed Wire Board 
Assemblies (PWBAs); two for the Ynet interfaces, a memory 
board, and a processor board. The COP also requires an 
adapter board for the local area network. 

Power Requirements 

A DBC/1012 cabinet group requires one branch circuit 
providing 208V, 30A, three-phase, five-wire, wye-connected 
power. Power distribution is determined by the system 
hardware configuration. Each cabinet group requires an AC 
power receptacle and branch circuit. 

Air Conditioning Requirements 

The DBC/101 2 subsystems are cooled by fans that draw air in 
through the bottom of the cabinet and circulate it out 
through the top. The number of subsystems in the 
configuration determine the amount of heat produced. A 
fully loaded processor cabinet emits approximately 8400 
BTU/hour. A full storage cabinet is rated at 8090 BTU/hour. 

For further information regarding the architecture of the 
DBC/1012 and site planning details, please refer to the 
following Teradata publications: C02-0001 DBC/1012 Data 
Base Computer Concepts and Facilities, C07-0001 DBC/1012 
Data Base Computer Planning Guide. 

THE RESULT: DATA BASE COMPUTING 

The DBC/101 2 is a complete system offering the full 
functionality and productivity of the relational model. In 
servicing the needs of programmers and information users, 
the DBC/1012 offers: 

• Superior responsiveness and throughput due to its parallel 
processing architecture. 

• Consistent data availability through fault-tolerant 
redundancy. 

• The ability for multiple users and multiple hosts to share a 
common data resource. 

• Modular sizing to accommodate the workload of today's 
requirements as well as the unknown of tomorrow. 

These benefits combined with the price/performance ratio 
define the new generation of data management: data base 
computing — enabled by the Ynet, delivered by Teradata. 



1/87 Printed in U.S.A. 



®1987 Teradata Corporation. 

DBC/1 01 2 and Ynet are trademarks of Teradata Corporation. 
NOMAD is a registered trademark of D&B Computing Services, 
IDEAL is a registered trademark of Applied Data Research. 
CCOS is a trademark of Honeywell Information Systems, Inc. 



Inc. 



■ 



Offices: Atlanta, Boston, Chicago, Cincinnati, Dallas, Detroit, Florida, 
Los Angeles, New York/New Jersey, San Francisco, Seattle, 
Washington, D.C., Toronto, Canada, and the United Kingdom. 



TERADATA CORPORATION 

12945 Jefferson Boulevard 
Los Angeles, CA 90066 

(213) 827-8777 






ss. 



"We call the Ynet "the Enabler" because it is the mechanism that 
allows us to fully exploit parallel processing and make cost effective 
relational data base computing possible." 

— Dr. Jack E. Shemer 
Chairman of the Board 



The Ynet™ is a Teradata® patented invention. It is a breakthrough 
in multiprocessor system organization. As "the Enabler," it 
harnesses the power of up to 1024 microprocessors operating 
in parallel to provide information faster, more easily, and in 
a more cost efficient manner than ever before. 

The Ynet is a redundant array of active logic. This logic 
provides selection and sorting functions for the Data Base 
Computer System. Requests for information that come from 
Communication or Interface Processors are broadcast to the 
correct Access Module Processors via the Ynet. The resulting 
information is then merged by the Ynet and delivered back 
to the user. 

This ability to interconnect many processors solves the 
long-standing problem of building large parallel processing 
systems. The Ynet allows processors to operate 
autonomously, without contention for centralized control. 
Thus, as new processors are added, a linear improvement in 
performance and throughput is realized. And, because of the 
Ynet's redundancy, system availability is exceptional. 

The Ynet is the heart of the DBC/1 01 2® architecture. No 
other architecture available today can provide — on such a 
large scale — the cost-effective processing power that is 
harnessed by the Ynet. Since relational data base computing 
is inherently a parallel process, the DBC/1 01 2 makes the 
relational model more efficient and therefore more practical 
and accessible. 
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The name Ynet is derived from the schematic representation 
of the basic interconnect subsystem, a network of high-speed 
circuits that resemble upside-down Ys arranged in a tree 
structure. The upside-down letter Y, highlighted in Figure 1, is 
also symbolized in the Teradata logo. 

A DBC/1012 system includes two independent, fully 
redundant Ynets. Each Ynet is an intelligent network that 
interconnects all Interface Processors (IFPs), Communication 
Processors (COPs), and Access Module Processors (AMPs). 
The Ynet performs — in high-speed hardware — many of the 
complex tasks associated with multiprocessor system 
management. 

As fully independent networks, each Ynet has physically 
separate circuits with separate power supplies. Each processor 
is connected to each Ynet. This redundancy, combined with 
integrated recovery logic, insures high availability of the 
system. In normal operation the two networks share the 
traffic load. However, if one network malfunctions, the other 
Ynet performs all necessary system activities. 

The basic Ynet configuration or node module, depicted in 
Figure 1, consists of seven nodes connected to the Ynet 
interfaces of eight processors. This figure shows only one of 
the dual Ynets. In reality, each processor is connected to the 
other Ynet as well. 

The Ynet operates in the DBC/1012 as a switching 
mechanism passing messages from Interface and 
Communication Processors to Access Module Processors and 
back. Simply explained, work steps from an IFP or COP travel 
up the node module hierarchy and then down, directed 
toward a single AMP (as in a prime key request) or fanning 
out to a number of AMPs (as in a request for multiple rows). 
Contention logic (for sorting) is applied in the upward path. 
In the downward path, the nodes operate in simple 
broadcast mode. Since all nodes operate from a common 
clock, all communication within the Ynet is synchronous. 

Because of the Ynet design, the DBC/1012 is easily and 
dynamically expanded with the addition of subsequent node 



modules. It allows the interconnection of as many as 1024 
processors in excess of 1000 MIPS of processing power. 
Figure 2 shows node expansion modules connecting eight 8- 
processor cabinets into a 64-processor configuration. In this 
diagram, both Ynets are shown in concurrent operation. With 
the addition of only two more node expansion levels, the full 
1024 processor system can be configured. 

And, as the DBC/1012 expands, performance grows linearly 
with its number of processor modules. For instance, if the 
configuration doubles in size, performance is twice as good 
— therefore, the larger it grows, the faster it goes — an 
important benefit for relational data base processing. The 
result is rapid responses even to complex queries. 

Storage capacity grows linearly as well. The user is no 
longer concerned with physical distribution. To accommo- 
date growth, the Ynet permits the automatic restructuring of 
the data. It gives the DBC/1 01 2 the capability to manage 
over 1 trillion (1 12 ) bytes of information. This fact led us to 
our name — Tera, the scientific prefix for "trillion" — hence 
Teradata. 

The Ynet is truly a remarkable achievement. It was an 
innovative outgrowth of the Teradata engineering 
organization. The DBC/1012 is the first application of this 
concept. 

Like most really significant ideas, the Ynet is very simple. 
The astonishing thing is how it solves the complex problems 
of parallel processing. It is an elegant answer for the first data 
base computing system — a system that delivers superior cost 
performance, processing efficiencies, modular growth and 
great expansion capabilities — the Teradata DBC/1012. 

The Ynet is truly a remarkable engineering achievement. A 
simple "Y" circuit with active logic to solve the complex 
problems associated with parallel processing. It is "the 
Enabler" that makes data base computing possible. 



A typical 8-processor system. Note that two Ynets operate concurrently. 
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Figure 1: Basic Ynet Configuration 



Figure 2: Multi-Level Network Configuration 
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"Why is DBC/SQL easy to use? Because the user only needs to tell 
the DBC/1012 what data he wants — not how to get it. That's up to 
the DBC/1012." 

— Dr. Philip M. Neches 
Chief Scientist 

The product of any data base system is information. However, 
the demands of today's business climate have surpassed the 
ability of traditional systems to deliver that product. The 
result is costly development and unmet backlogs. 

To be productive, information must be quickly delivered to 
the people who need it, when they need it, and in a form 
that they can use. Moreover, information should be obtained 
with the least amount of effort: ask a question, receive a 
reply. 

The relational model data base approach' answers many of 
these problems. Yet, all-software implementations of the 
relational model lack the performance and reliability to 
support a meaningful community of data base users. In 
recognition of this deficiency, a leading mainframe vendor 
cites the need for "significantly more systems resource — both 
machine cycles and memory." 

The Teradata distinctive solution enriches the relational 
model with special purpose, high-performance hardware, and 
DBC/SQL — a unified, multi-purpose data base language that 
satisfies the needs of both programming professionals and 
direct end-users. DBC/SQL is Teradata's implementation of 
the emerging industry-standard SQL data base language. 
Simple English-like statements evoke rapid response, and 
information is delivered easily and quickly. 

All functions of the DBC/1012™ — data definition, data 
manipulation, query, and report writing — are handled by 
DBC/SQL commands. Statements may be issued directly by 
interactive terminal users or they may be embedded within 
application programs. 

This powerful, easy-to-learn language allows a broad 
community to access and manipulate the date base. End- 
users without programming skills can master the system 
within a short period of time. Programmers and analysts can 
develop applications much quicker than before. Finally, with 
the DBC/1012 there is one language that meets the needs of 
nformation users and production systems, without 
compromises that favor one use or the other. 

DBC/SQL provides full availability of the relational model 
for data base management — an approach that both 
simplifies and expedites the processing of information. The 
relational model is a more productive tool than the systems 
of the past. Now DBC/SQL and the DBC/1012 deliver the 
winning combination — the productivity benefits of the 
relational approach with levels of cost/performance and 
reliability unmatched by prior systems. 




DBC/SQL 



The Relational Approach 

The key benefits of the relational model data base approach 
come from its simplicity. Data are seen in tables — the way 
most people work with related pieces of information every 
day. This familiar view of data permits programmers and end- 
users alike to easily understand and use the data base. 

The DBC/SQL language allows the user to retrieve and 
manipulate tabular data in a non-procedural fashion — that 
is, without iterative loop processing and step-by-step 
navigation. With DBC/SQL, the user states what is needed, 
but not how to get it. Thus, an entire table or data base may 
be handled with a single statement, rather than numerous 
lines of procedural programming code. 

Tables: The Basic Data Structure 

Figure 1 depicts two relational tables. Each table (relation) 
has a name: Employee and Department. Each vertical column 
has a name. The horizontal rows are the entries or instances 
of the relation. All rows have the same data format. The 
intersection of a column and a row is called a field. 

All data in a table can be modified. Rows may be added or 
deleted and individual fields may be changed. Similarly, 
entire columns may be altered, deleted or added to an 
existing table. The user has total control of the data. 









EMPLOYEE 








EmpNo 


Name 


DeptNo 


Position 


Salary 




10001 


Peterson J 




100 


Bookkeeper 


25,000.00 




10002 


Moffit H 




100 


Recruiter 


35,000.00 






10003 


Smith T 




500 


Engineer 


42,000.00 






10004 


Jones M 




100 


Vice Pres 


50,000.00 






10005 


Kemper R 




600 


Assembler 


29,000.00 






10006 


Marston A 




500 


Secretary 


22,000.00 






10007 


Reed C 




500 


Technician 


30,000.00 






10008 


Watson L 




500 


Vice Pres 


56,000.00 






10009 


Regan R 




600 


Manager 


44,000.00 






10010 


Carter J 




500 


Engineer 


44,000.00 






10011 


Greene W 




100 


Payroll Ck 


32,500.00 






10012 


Russell S 




300 


President 


65,000.00 






10013 


Newman P 




600 


Test Tech 


28,600.00 






DEPARTMENT 






DeptNo 


DeptName 


Loc 




100 


Administration 


NYC 






300 


Exec Office 


NYC 








500 


Engineering 


ATL 








600 


Manufacturing 


CHI 







Figure 1 



Relational Operations 

It is easy to access relational tables. The operations of the 
relational model can deal with an entire table, portions of a 
table or multiple tables. 

The following DBC/SQL statement will deliver the entire 
sample employee table — that is, all rows and columns: 



SELECT 
FROM 



Employee; 



Often, users will only need to access some of the columns 
and/or rows. The relational operations "select" and "project" 
do this. 



The DBC/SQL "project" operation restricts the columns 
returned. For example, the statement shown below narrows 
the return of employee data from five columns to two — 
employee name and position: 



SELECT 
FROM 



Name, Position 
Employee; 



The "select" operation restricts the rows returned. As the 
following DBC/SQL statement illustrates, the WHERE clause is 
used to specify row selection: 



SELECT 

FROM 

WHERE 



Employee 
DeptNo=500; 



The "select" and "project" operations may be used together, 
as well, as in this example: 



SELECT 

FROM 

WHERE 



Name, Position 

Employee 

DeptNo=500; 



A third relational operator, called the "join", combines data 
from two or more tables. The following example uses the 
tables from Figure 1 : 

SELECT Name, Employee. DeptNo, Loc 

FROM Employee, Department 

WHERE Employee. DeptNo= Department. DeptNo; 

This example combines the name and department number 
from the employee table with the location from the 
department table. The value of the department number is 
common to both tables and is the "link" used to "join" the 
tables. 

Ordering 

DBC/SQL provides the ability to present information in any 
order desired. The relational model can order returned 
information in two ways: horizontally (by column) and 
vertically (by row). For instance, the DBC/SQL statement 
below asks for data in a different column order than exists on 
the employee table: 

SELECT DeptNo,Name,Salary 
FROM Employee; 

The ORDER BY clause controls vertical (row) sequencing. For 
instance: 

SELECT DeptNo.Name.Salary 
FROM Employee 

ORDER BY DeptNo; 

Any field or combination of fields may be stipulated in the 
ORDER BY clause. Thus, the user could have this return in 
department number, name or salary order. The next example 
results in a major sort by department number, and a minor 
sort by salary: 

SELECT DeptNo.Name.Salary 
FROM Employee 

ORDER BY DeptNo.Salary; 






Data Maintenance Functions 

The DBC/SQL language may also be used to CREATE tables 
and maintain them. New rows are added to a table with the 
INSERT statement. Existing rows can be modified by using the 
UPDATE command or eliminated with the DELETE command. 
Using the UPDATE as an example, the following statements 
illustrate how a DBC/SQL command can be used to maintain 
either a single row or a selection of multiple rows: 

UPDATE Employee SET Position='Accountant' 
WHERE EmpNo=10001; 

UPDATE Employee SET Salary=Salary * 1.1 
WHERE DeptNo=500; 

Views 

A view is an "apparent" table derived from one or more 
"real" tables. The view allows data to be tailored to users' 
perceptions and needs without redesigning the database. For 
instance, assume that a group of users require a view of the 
sample tables in Figure 1 . They commonly need to know the 
employee name, department name and location. They do 
not need to know the position or salary. The following 
statement prepares an appropriate view: 

CREATE VIEW Directory (Name,DeptName,Loc) 

AS SELECT Name.DeptName.Loc 
FROM Employee.Department 
WHERE Employee.DeptNo= Department. DeptNo; 

Users of this view may deal with the Directory view as if it 
was a real table with three columns — Name,DeptName and 
Loc: 

SELECT Name 
FROM Directory 

WHERE Loc='NYC; 

Views simplify formulating requests and function as a data 
security mechanism by precisely limiting access to 
information to that which is required. 

ITEQ — Interactive Use of DBC/SQL 

DBC/SQL statements may be embedded in application 
programs or issued to the DBC/1012 interactively through the 
ITEQ (interactive TEradata Query) facility. 

ITEQ provides functions for controlling terminal operations 
during a dialogue with the DBC/1012. DBC/SQL statements 
may be directly entered, edited and executed. The user may 
format outputs, compose reports, and create macros. 

ITEQ, together with DBC/SQL, presents a powerful set of 
report writer features. Data can be formatted for terminal 
display and prepared for printing. Formatting can: 

• Center information 

• Show summary information (for example, totals and 
subtotals by groups) 

• Specify a report title, which automatically appears centered 
at the top of each display or printed page along with the 
current date and page number 

• Change column headings and column summary titles 

• Specify the format for numeric fields (for example, 
suppression of leading zeros, number of decimal places to 
appear) 

• Establish printer page size (width and length) 

• Cause a report file to be created and sent to a printer 



Screen A shows a typical ITEQ display result. The screen 
shows the results from the DBC/1012 at the top and the 
user's request at the bottom. If the user wishes to further 
format the data for a report, the input statement may be 
edited using ITEQ and resubmitted to the DBC/1012. For 
example, by adding a WITH clause to the SELECT statement, 
the user can produce subtotals for each department. Screen B 
shows the modified input statement and the resulting 
response. 

ITEQ automatically uses names from the DBC/1012 Data 
Dictionary/Directory for column headings. However, the user 
may change these names. The example in Screen C shows 
how DeptNo can be changed to DeptNumber and SUM 
Salary to Dept TOTAL to customize a report. 






DeptNo 



Name 



Salary 



100 


Greene W 


32,500.00 


100 


Jones M 


50,000.00 


100 


Moffit H 


35,000.00 


100 


Peterson J 


25.000.00 


500 


Carter J 


44,000.00 


500 


Marston A 


22,000.00 


500 


ReedC 


30.000.00 


500 


Smith T 


42,000.00 


500 


Watson L 


56,000.00 



WHERE DeptNo IN (100. 500) 
ORDER BY DeptNo, Name; 



Screen A 



'RETRIEVE COMPLETED. 9 RE iJRNED. 

MAXIMUM LINE WIDTH IS 32 CHARACTERS. 
DeptNo Name Salary 



100 


o ■ ..: : 


32.500.00 


too 


iC'i : : ■'! 


50,000.00 


100 


Moffit H 


35,000.00 


100 


SUM Salary 


25,000.00 




142,500.00 


500 


Carter J 


44,000.00 


500 


./., : ..- r 


22,000.00 


500 


Reed C 


30,000.00 


500 


Smith T 


42,000.00 


500 


Watson L 

SUM Salary 


56,000.00 




194 000 00 



WHERE Deptf I00) 

WITH SUM (Salary) BY DeptNo 

ORDER BY DepiN . ' 



Screen B 



MAXIMUM LINE WIDTH IS 32 CHARACTERS. 

Dept 
Number Name Salary 



100 
100 
100 
100 


Greene W 
Jones M 
Moffit H 
Peterson J 

Dept TOTAL 
Carter J 
Marston A 
ReedC 
Smith T 
Watson L 

Dept TOTAL 
DeptNo (TITLE 'Dept//NL 
Employee 

DeotNo IN (100, 500) 
V! (Salary) (TITLE 'Dept TO 
Y DeptNo, Name; 


32,500.00 

35.000.00 
25,000.00 


500 
500 
500 
500 
500 


142,500,00 
44,000.00 
22,000.00 

42.000.00 

; 


= => SELECT 
FROM 
WHERE 
WITH SU 

V__^3RDER B 


194 QUO 00 
mber'), Name, Salary 

TAL] BY DeptNo 



Screen C 
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BTEQ — Batch Use of DBC/SQL 

DBC/SQL statements may also be issued to the DBC/1012 as 
a batch job through the facility called BTEQ (Batch TEradata 
Query). 

BTEQ also provides the user with a powerful set of report 
writer features. Data can be formatted for printing or 
exported to a host data set for further processing. 

The following example shows "how BTEQ can be used to 
generate a report: 

• SET FORMAT ON 

•SET RTITLE 'Departmentalized Salary Report' 

SELECT DeptNo (TITLE ' Dept//Number '), Name , Salary 

FROM Employee 

WHERE DeptNo IN (100,500) 

WITH SUM (Salary) (TITLE ' Dept TOTAL ') BY DeptNo 

ORDER BY DeptNo, Name; 



RETRIEVE COMPLETED. 9 RECORDS FOUND. 3 COLUMNS RETURNED. 
MAXIMUM LINE WIDTH IS 32 CHARACTERS. 

















Page 1 


9/15/85 


Departmental 


Lzed 


Sal 


ary 


Report 




Dept 
















Number 


Name 








Sal^ 


ry 




100 


Greene W 






32 


500 


00 




100 


Jones M 






50 


000 


00 




100 


Moffit H 






35 


000 


00 




100 


Peterson J 






25 


000 


00 






Dept 


TOTAL 


142 


500 


00 




500 


Carter J 






44 


000 


00 




500 


Marston A 






22 


000 


00 




500 


Reed C 






30 


000 


00 




500 


Smith T 






42 


000 


00 




500 


Watson L 






56 


000 


00 






Dept 


TOTAL 


194 


000 


00 





Macros 

Macros save time by simplifying a complex entry and 
reducing errors in keying. A macro is a set of DBC/SQL 
statements, stored on the DBC/1012 with a macro name, that 
the system will execute as a single transaction. A simple 
EXECUTE followed by the macro name will cause the stored 
DBC/SQL statements to be processed. 

Application Program Interface 

DBC/SQL statements may also be issued from within an 
application program. Any programming language with a CALL 
facility can direct DBC/SQL commands to the DBC/1012 
through the Teradata Call-Level Interface (CLI). This 
interchange is similar to the CALL structures of traditional 
data base systems. 

Teradata offers preprocessors for COBOL and PL/1 which 
simplify the coding tasks by allowing the programmer to use 
high level DBC/SQL statements intermixed with COBOL or 
PL/1 statements. The Teradata COBOL and PL/1 
Preprocessors run in the host computer as a batch job. Before 
a source program is compiled, the preprocessor scans the 
program for embedded DBC/SQL statements identified by a 
prefix delimiter, normally a ? character. The preprocessor 
adds appropriate expansions and CALLS that handle the 
actual program interface, and thus relieve the programmer of 
dealing with the low level details of the interface. 



The sample COBOL code shown below illustrates how easily 
a DBC/SQL statement may be used. This structured code 
receives an input department number, retrieves the salary 
statistics for the department from the DBC/1012, and then 
places the results into an appropriate COBOL work area. Error 
control is provided by the Preprocessor ONERROR facility. 



03 53 0*********************************************************** 

035400 2210-8EPORT-DEPARTHENT SECTION. 

035450 

035500 HOVE "DEPARTHENT SALART STATS* TO REPORT-TITLE. 

035560 HOVE ZERO TO PAGE-NUHBER. 

035700 

035800 7SELECT DEPARTMENT. DEPTNO, DEPTNAHE, 

035900 ? AVG(SALARJ), H I N (SALART) , flAX(SALARY) 

036000 ? EROH DEPARTHENT, EHPLOYEE 

036100 ? INTO DEPT-SAL-STATISTICS 

036200 ? WHERE DEPARTHENT. DEPTNO=EHPLOYEE. DEPTNO 

036300 ? AND DEPARTHENT. D £PTN0= : DEPT- VALUE-IN PUT J 

036400 

036500 ?ONERROR ( NO-STJCH-DE PT , 221 0- DEPT- ERROR , 

036600 ? OTHERWISE, SNAP) ; 

036700 

036800 PERFORH 3920- U RITE- PRINTER. 

036900 GOTO 2210-EXIT. 

037000 

037100 2210-DEPT-ERROR. 

037250 

037300 HOVE 'INVALID DEPARTHENT NUnBEH" TO ERROR-H ESS AGE . 

037460 PERFORH 321 0-PRI NT- ERROR. 

037500 

037600 2210-EIIT. 

037700 EXIT. 



Controlling Data Access 

The ability to control access to sensitive data is an important 
DBC/SQL strength. Specific access privileges are GRANTED to 
each user of the system — depending on the data needed by 
and authorized for that individual. Typically, the granting of 
privileges is managed by the Data Base Administrator or by 
his or her delegate — that is, an individual who has been 
granted the right to GRANT. Thus data remains secure, in a 
controlled and manageable system. 

Data Dictionary/Directory 

DBC/1012 software automatically maintains an active Data 
Dictionary/Directory. This facility catalogs all CREATED tables, 
views and macros as well as users of the system and their 
access rights. All modifications to such entries are 
automatically recorded. Numerous usage statistics are also 
dynamically stored in the dictionary during system operation. 

Because the Data Dictionary/Directory is a relational data 
base on the system, the customer can access its contents 
using DBC/SQL. Users can create tailored reports on data 
structures, user rights, and statistics for chargeback purposes. 

For further information regarding DBC/SQL, ITEQ and 
BTEQ, please refer to the Teradata documents CO3-0001 
DBC/1012 Data Base Computer Reference Manual and C09- 
0001 DBC/1012 Data Base Computer User's Guide. Should 
detail be needed for the Call-Level Interface (CLI), please 
request CI 2-0001 DBC/1012 Data Base Computer Host 
Interface Manual. 

Coordinated Products 

Users of the DBC/1 01 2 also need information delivery tools 
to enhance the usage of the stored data. Interfaces are 
available to software such as: NOMAD2 and FOCUS, 4th 
generation languages, IDEAL, a high-level application 
development tool, and PC/SQL-link, a SQL-based program 
supporting PC-to-mainframe interaction. 
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"At Teradata, our last customer is more important than the next." 

— Kenneth W. Simonds 
President 

Teradata is a company dedicated to a new spirit of support 
for its customers. It is committed to providing a level of trust 
and understanding for customer needs — not just hardware 
and a manual but a support system that meets these needs 
every step of the way. 

Teradata fulfills this commitment to support with a team of 
customer oriented professionals as well as accurate up-to- 
date documentation and education. Service begins in the 
field with veteran sales representatives, system engineers, and 
customer engineers. These individuals are in turn supported 
by active headquarters-based facilities; a'National Service 
Center, documentation, and education departments. 

Sensitivity to customer needs and preferences is the key 
theme. Teradata has been, and will continue to be, a 
company that listens and responds to its customers. 
Therefore, it will maintain the highest level of customer 
support — from the initial sale to installation, to user 
orientation and training, to software and hardware service. At 
Teradata, we believe that the customer's success with the 
DBC/1012™ Data Base Computer System will be mutually 
beneficial. 

Teradata Field Support 

Teradata provides its clients with five levels of direct support: 
the sales representative, the system engineer, the customer 
engineer, the National Service Center and customer 
education. These multiple levels ensure a quality service 
structure dedicated to meet every need, anticipated or 
unanticipated, from corporate, regional and field locations. 

Teradata Sales Representative 

The Teradata sales representative is the customer's focal point 
for communication. There is commitment that extends 
beyond securing the order. He or she feels a responsibility 
for the success of the customer's decision and will coordinate 
all Teradata resources to satisfy customer needs. 

System Engineer (SE) 

Teradata system engineers are viewed as an extension of the 
client's staff. They are prepared to answer technical questions, 
to assist in training, and to ensure the success of the 
applications. The SE is the primary service contact following 
the installation of the DBC/1 01 2. As such, he or she will stay 
in close contact with customer personnel. System engineers 
are also available on a consulting basis whenever help is 
needed. 




Service and Support 



1/87 Printed in U.S.A. 



Customer Engineer (CE) 

Teradata's commitment to service includes customer 
engineers trained to work with the customer from the initial 
site survey through equipment installation, upgrades, and 
repair. Backed by an extensive local spares inventory and in- 
depth systems software knowledge, these engineers are 
equipped to repair all possible system failures on the spot. 

National Service Center (NSC) 

Backing up the field organization is a trained corporate staff 
of National Service Center personnel. This staff includes 
senior system engineers and customer engineers with in- 
depth knowledge of the DBC/1012. The NSC is responsible 
for all reported problems and tracks each case to its 
conclusion. 

To provide troubleshooting advice, staff members have 
access to a customer data base where the history of previous 
problems and solutions can help in current problem 
diagnosis. In addition, the system developers are available 
should a question arise that needs their expertise. 

Customer Documentation 

The DBC/1012 Data Base Computer System is a powerful 
information management tool. In order to derive the 
maximum benefit from the system, its use must be quickly 
assimilated into the organization. Documentation is needed 
at several levels, from systems professionals to the end-users. 
Teradata provides the following set of manuals and guides. 

DBC/1012 Data Base Computer 

Concepts and Facilities CO2-0001 

This manual presents a general overview of the DBC/1012 

Data Base Computer System. 

DBC/1012 Data Base Computer 

Reference Manual CO3-0001 

This reference manual contains comprehensive descriptions 

of the major Teradata software: DBC/SQL, ITEQ, BTEQ, the 

COBOL and PL/1 Preprocessors, and the Data 

Dictionary/Directory (DDD). 

DBC/1012 Data Base Computer Reference Card CO4-0001 

This card summarizes the syntax of DBC/SQL statements; 

ITEQ and BTEQ commands; COBOL and PL/1 Preprocessor 

statements; DDD view formats; and Call-Level Interface entry 

points. 

DBC/1012 Data Base Computer Planning Guide CO7-0001 

This planning guide contains information required to prepare 

a customer site for installation of a DBC/1012. It includes a 

summary of physical planning issues, DBC/1012 hardware 

specifications, a physical planning template, and a summary 

of host system software installation procedures. 

DBC/1012 Data Base Computer User's Guide CO9-0001 

This guide describes how to communicate with the 

DBC/1012 in order to work with data stored on the Data Base 

Computer System. 

DBC/1012 Data Base Computer System Manual C1 0-0001 

This manual describes the administration of the DBC/1012 

and summarizes the procedures and utilities that support its 

maintenance. It also provides guidelines for designing 

efficient relational data bases. 



DBC/1012 Data Base Computer 

Utilities Reference Manual C1 1-0001 

This manual presents the utilities that are used to load, 

dump, and restore data, initialize and configure a DBC/1012 

system, and perform system maintenance. 

DBC/1012 Data Base Computer 

Host Interface Manual C1 2-0001 

This manual describes the host interface software that 

provides communication between host-resident user 

applications and the DBC/1012 Data Base Computer System. 

DBC/1012 Data Base Computer CICS 

Interface Manual C1 2-0002 

The CICS interface manual is written for programmers who 

access the resources of the DBC/1012 system through CICS. 

DBC/1012 Data Base Computer MVS/VM 

Host Software Manual C1 3-0001 

This manual describes the host-resident software components 

supplied by Teradata, SVC mode and cross. memory services 

mode under MVS, and corresponding operation under VM. 

DBC/1012 Data Base Computer 

Operator's Guide C1 5-0001 

The guide presents features of the DBC/1012 and its console, 

as well as their operating procedures, programs, and status 

indicators. 

DBC/1012 ITEQ Keypad Template C99-0002 

The template, which fits over the terminal keyboard's PF-key 

keypad, shows the assignment of PF keys to ITEQ commands. 

Education 

Teradata offers a complete educational program to acquaint 
customers with the DBC/1012 and its use. Classes offer labs, 
lectures, and workbook exercises with strong emphasis on 
student participation. Programs can be tailored to a client's 
needs and can be conducted either at Teradata education 
centers or at the client's site. A class schedule is available 
upon request. 

DBC/1012 Data Base Computer Concepts CU 100 

CU 100 provides an overview of the hardware and software 
subsystems of the DBC/1012 System. Duration: 1 day 
DBC/1012 Operations CU120 

CU 120 provides the customer data center personnel 
(operators and supervisors) with information necessary in the 
day-to-day operation of the DBC/1012 system. 
Duration: 1 day. 

System Administration CU210 

CU 210 teaches students how to handle system administra- 
tion, configuration issues, and software maintenance 
procedures. Prerequisite: CU 100. Duration: 2-3 days. 
DBC/1012 Language: DBC/SQL/ITEQ/BTEQ CU 220 

CU 220 enables the student to become proficient in 
DBC/SQL, ITEQ and BTEQ through hands-on experience in 
the lab. Prerequisite: CU 100. Duration: 2-3 days. 
Data Base Design CU 215 

CU 215 presents performance considerations when designing 
a relational data base for the DBC/1012. Prerequisite: CU 100. 
Duration: 2-3 days. 
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